APPENDIX 



1. Title: METHODS AND SYSTEMS FOR ROUTING MESSAGES IN A 
COMMUNICATIONS NETWORK 



METHODS AND SYSTEMS FOR ROUTING MESSAGES IN A 
COMMUNICATIONS NETWORK 



AN APPLICATION FOR 
UNITED STATES LETTERS PATENT 



By 

Thomas Matthew McCann 
Morrisville, North Carolina 

Raghavendra Gopala Rao 
Cary, North Carolina 

Robert Fulton West, Jr. 
Cary, North Carolina 



10 



' Atty Dkt No 1322/28/3 -1" "Express Mail" mailing number EF319341 101 US 

Date of Deposit December 22. 2000 

I hereby certify that this paper or fee is being deposited with the 
United States Postal Service "Express Mail Post Office to 
Addressee" service under 37 C F R 1 10 on the date indicated 
above and is addressed to the Commissioner of Patents, 



Karen S Flynn 



Description 

METHODS AND SYSTEMS FOR ROUTING MESSAGES IN A 
COMMUNICATIONS NETWORK 

Related Application Information 
This application is a continuation-in-part of United States Patent 
Application Number 09/471,946 filed December 23, 1999, the disclosure of 
which is incorporated herein by reference in its entirety. 

Technical Field 

The present invention relates to the routing of signaling messages in a 
communications network, and, more particularly, to methods and systems for 
providing a switching node that incorporates flexible message routing 
functionality. 



Background Art 

Within the global wireless telecommunications industry, the current 
trend in network technology is divided between Global System for Mobile 
20 Communications (GSM) and American National Standards Institute (ANSI)-41 
based architectures. In many respects, GSM and ANSI-41 based networks 
are quite similar, with the primary differences between the two technologies 
simply relating to the protocols used to communicate between the various 
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network entities, and the operating frequencies of the communication 
handsets themselves. As such, in the interest of clarity, discussions of the 
present invention will henceforth be limited to GSM type network 
implementations. However, it should be appreciated that the present 
5 invention could be similarly practiced in an ANSI-41, Personal Communication 
Services (PCS) or similar type network. 

A typical GSM network architecture is illustrated in Figure 1. As shown 
in Figure 1, the typical GSM network, generally indicated by the numeral 100, 
incorporates a number of functional elements or nodes which are 

10 appropriately interconnected so as to obtain the desired overall network 
service. These network nodes include a Home Location Register (HLR) 116, 
a Visitor Location Register (VLR) 118, an Equipment Identification Register 
(EIR) 120, an Authentication Center (AuC) 122, a Mobile Switching Center 
(MSC) 110, a Gateway Mobile Switching Center (GMSC) 112, an Inter- 

15 Working Mobile Switching Center (IWMSC) 132, and a Short Message 
Service Center (SMSC) 130. Briefly, the HLR 116 is a database that is used 
to store subscriber information for all customers within the home service area 
of the GSM service provider. Functionally, the HLR 116 is linked through a 
signaling network to other service areas such that subscriber information may 

20 be efficiently shared between geographically diverse networks, a 
characteristic that facilitates seamless inter-network roaming. Like HLR 116, 
the VLR 118 is also a database that contains subscriber information. 
However, the VLR 118 is specifically used to store information related to 
subscribers who are not in their home service area. More particularly, the 

25 VLR 118 is where roaming related data for a customer is stored when the 



customer activates their handset outside of their designated home service 
area. The EIR node 120 retains information related to the identification serial 
numbers of all customer handsets that have been activated within the service 
area, while the AuC node 122 contains security or encryption key data 
associated with each of the handsets. SMSC 130 serves primarily as a store- 
and-forward mechanism for subscribers to send Short Message Service 
(SMS) messages to other mobile subscribers or computer systems. 

The five network elements described above (HLR, VLR, EIR, AuC, 
SMSC) can be thought of as essentially databases or database processing 
nodes. Unlike these database nodes, the MSC 110, GMSC 112, and IWMSC 
132 are generally identified as network switching elements. Among their 
many functions, the MSC 110 and GMSC 112 are responsible for determining 
which cell site will take possession of a call. Such hand off control is 
facilitated by a communication link between the MSC 110 and an associated 
Base Station Controller (BSC) / Base Transceiver Station (BTS) pair 124. 
The GMSC 112 has the added distinction of providing a gateway interface to 
the Public Switched Telephone Network (PSTN) 114; otherwise, MSC 110 
and GMSC 112 functionality is very similar. Furthermore, as generally 
illustrated in Figure 1, the GMSC 112 is also coupled via signaling links to the 
four database nodes described above, and as such, all signaling message 
access to these database nodes is controlled and administered by the GMSC. 
Although not illustrated in Figure 1, the MSC may also be coupled directly to 
the database nodes. IWMSC 132 is typically an MSC 110 or a GMSC 112 
that also has the function of inter-working between the SMSC 130 and the 
rest of the mobile network. 



Of particular relevance to the present invention are the signaling 
aspects of the GSM network described above, especially those aspects 
associated with the signaling interactions between an HLR or SMSC database 
node and an MSC or GMSC type node. In order to better understand these 
5 signaling interactions, a more detailed explanation of HLR operation is 
provided below. 

Within a GSM wireless communication network, each mobile station 
handset 128 is assigned a unique identification number known as an 
International Mobile Subscriber Identity (IMSI) identification number. In the 

10 case of European GSM - type network implementations, the IMSI code is 
typically associated with a particular telephone handset. In such networks, 
each user can also be assigned one or more Mobile Station Integrated 
Services Digital Network (MSISDN) numbers. In the wireless 
telecommunications industry, MSISDN numbers are analogous to the 10 digit 

15 telephone numbers in a conventional North American wired network. The fact 
that multiple MSISDN numbers can be associated with a single IMSI number, 
indicates that more than one MSISDN number can be assigned and used to 
reach a single mobile station handset. It should be appreciated that in this 
disclosure, the term "Mobile Identification Number" (MIN) is used generically 

20 to refer to IMSI, MSISDN, Mobile Global Title, ANSI-41 Mobile Identification 
Numbers (MIN) and Mobile Directory Numbers (MDN), and other identification 
numbers associated with subscribers or services in a wireless communication 
network. 

In any event, an MSISDN number is dialed whenever a user wants to 
25 communicate with a particular mobile station handset. An MSC or GMSC, by 



analyzing a part of the dialed MSISDN number, determines the particular HLR 
that is storing routing information associated with the called mobile station. By 
retrieving and utilizing such routing information, the GSM network is able to 
locate the called mobile station in response to a call attempt so that a call 
connection can be established between the calling party and the called mobile 
station. It should also be appreciated that, depending on the nature of the call 
or signaling event, an MSC may alternatively analyze and perform the HLR 
lookup based on the IMSI or MSISDN number associated with the called or 
calling party. 

Figure 2 illustrates a typical GSM network architecture, generally 
indicated by the numeral 150, which includes a GMSC 154 that is linked to 
both an MSC 152 and a single HLR unit 156. GMSC 154 includes a routing 
table 160, while HLR 156 includes a database table 158. Figure 3 also 
illustrates a typical GSM network architecture, generally indicated by the 
numeral 180, which includes a GMSC 182 linked to several HLR units. More 
particularly, GMSC 182 is coupled via signaling links to HLR A 186, HLR B 
190, and HLR C 194, and necessarily to HLR database tables 188, 192, and 
196, respectively. 

In the examples illustrated in both Figures 2 and 3, each of the HLRs is 
configured to service a pre-defined block of subscriber MSISDN numbers. In 
general, a specific series or block of MSISDN (or IMSI) numbers are pre- 
assigned to each HLR in a service provider's network. It should be 
appreciated that the HLR database and GMSC Routing Table structures 
shown in Figures 2 - 3 are merely illustrative of the high level information 
storage concept and are not intended to represent the actual data structures 



that would typically be implemented in such network nodes. In many cases, 
service providers are not able to alter these blocks of assigned numbers 
within a given HLR unit because of routing limitations of the MSC associated 
with the HLR unit. Consequently, service providers have no opportunity to 
dynamically re-allocate their MSISDN number base across multiple HLRs, so 
as to more efficiently utilize existing HLR resources (i.e., load sharing). It 
should be noted that this limitation is typically the result of routing table 
restrictions in the MSCs, and generally not database storage restrictions in 
the HLRs. That is, although HLRs can generally be populated so as to 
contain subscriber data entries for any IMSI or MSISDN number, MSCs are 
typically only capable of routing messages based on an IMSI or MSISDN 
block in which the message's IMSI or MSISDN number falls. These IMSI or 
MSISDN blocks are comprised of a sequential range of IMSI or MSISDN 
numbers. Thus, it is the limited routing capability of an MSC or a GMSC that 
causes the problem, and typically not the HLR nodes. 

For instance, in Figure 2, all traffic relating to calls associated with an 
MSISDN number between 9199670000 and 9199679999 will be routed to 
HLR A 156 by the associated GMSC 154. As the service provider begins to 
acquire more and more customers (i.e., assigning more and more of the 
MSISDN numbers in the allocated block or series 9199670000 to 
9199679999), the traffic or congestion experienced at the HLR A 156 node 
will increase accordingly. 

Now consider that a service provider owning the network elements 
illustrated in Figure 2 has acquired so many new customers that it is decided 
to invest in an additional pair of HLRs. This scenario is generally illustrated in 



Figure 3, where the two additional HLRs are identified as HLR B 190 and HLR 
C 194. At the time of implementation HLR B 190 is populated with MSISDN 
number block 919968000 - 9199689999, and HLR C 194 is populated with 
MSISDN number block 9199690000 - 9199699999. These two HLRs are 
linked to the adjacent GMSC 182 and activated so as to service any calls 
corresponding to their pre-programmed MSISDN blocks. 

The major shortcoming of such multiple HLR configurations can now 
be more fully appreciated. As generally indicated in Figure 3, despite the 
addition of the new HLR resource capacity represented by units B and C, all 
call traffic associated with MSISDN numbers 9199670000 - 9199679999 
must still be handled by a single HLR, HLR A 188. Even if the service 
provider has no customers within the MSISDN 9199680000 - 9199699999 
number range, it is not possible for the service provider to dynamically re- 
allocate or re-distribute the "fully assigned" 9199670000 - 9199679999 
MSISDN number block among the unused HLR B 192 and HLR C 196 units. 
Thus, it is quite possible that the service provider will operate in a situation 
where traffic to HLR A 188 is highly congested, while the HLR B 192 and HLR 
C 196 resources are completely unused. This can lead to less than efficient 
usage of installed resources, as it would be more efficient to load balance or 
share traffic more equally among the three HLR units. 

It should be appreciated that, in addition to the load sharing concerns, 
there are similar issues and similar needs that arise when considering the 
porting of subscribers from one service provider to another, otherwise known 
as local number portability (LNP). Once again, the central problem is the 
ability to freely distribute subscriber information among multiple HLR nodes. 



A detailed discussion of the specific problems associated with LNP is not 
provided in this disclosure, as the high-level issues and concerns are the 
same as those for the load sharing scenario described herein. 

United States Patent No. 5,878,347 to Joensuu, et al. . (hereinafter, "the 
'347 Patent") the disclosure of which is hereby incorporated by reference in its 
entirety, discloses one approach to solving some of the problems identified 
and discussed above. The solution described in the '347 Patent involves the 
implementation of a new network element, referred to as a virtual HLR 
(vHLR). Figure 4 of the present application and the following description 
illustrates the function of the vHLR in the '347 patent. Referring to Figure 4, a 
vHLR node 214 is placed in the communication network pathway between a 
GMSC 212 and a plurality of HLR nodes, HLR A 218, HLR B 222, and HLR C 
226. HLRs 218, 222, and 226 contain subscriber databases 220, 224, 228, 
respectively. The GMSC 212 sends signaling messages to the vHLR node 
214 requesting subscriber information where the particular subscriber is 
associated with an IMSI or MSISDN type mobile station identification number. 
The vHLR 214 does not contain subscriber information; rather, the vHLR 214 
contains a routing table 216 that correlates IMSI or MSISDN numbers with a 
particular HLR. More particularly, the routing table 216 contains information 
relating IMSI or MSISDN numbers to a corresponding network address 
associated with the HLR serving that IMSI or MSISDN subscriber. 

The message routing technique disclosed by the '347 Patent is a key 
element of the invention described therein. As generally illustrated in Figure 
4, when the vHLR node 214 receives a message 234 from the associated 
GMSC 212, the message is addressed to and is delivered directly to the vHLR 



node 214. The vHLR node 214 performs a table lookup, as described above, 
and re-routes the message to the appropriate HLR node, in this case HLR C 
228. This re-routing function is accomplished by altering the destination point 
code (DPC) of the message 236 routing label, such that the original DPC 
(PC=vHLR) is replaced by a new DPC (PC=HLR C). It is significant, and 
should be noted that the vHLR node 214 does not alter the origination point 
code (OPC) of the message routing label. That is, the OPC of the incoming 
message 234 is the same as the OPC of the outgoing message 236, which is 
the point code of the GMSC 212. Thus, the message arrives at HLR C 228 
with an OPC equal to the point code of GMSC node 212. HLR C 228 then 
responds with a message 238 that is addressed to the GMSC 212. The HLR 
C response message 238 is not routed back through the vHLR node 214. 

While such a routing technique may save one or more routing "hops", 
from a network management perspective, this routing technique presents at 
least one significant problem. That is, in the event that an HLR should 
become unable to provide service, SS7 signaling convention requires that the 
HLR send a message to any signaling point (SP) that is attempting to 
communicate with it, alerting the SP to the impaired or out-of-service status of 
the HLR. Given the message flow described above, it will be appreciated that 
in such an out-of-service scenario, HLR C 226 would send a network 
management message to the originator of the incoming HLR C message 236. 
The originator of the incoming HLR C message 236 is identified by the OPC 
field of the message 236 routing label. As described above, the vHLR 214 
node does not alter the OPC field of the routing label, but instead leaves the 
OPC set to the address of the GMSC 212. Thus, network management 



messages sent by HLR C 226 will be addressed to the GMSC 212. The 
problem with such a message routing scheme is that the GMSC 212 has no 
"knowledge" of having sent a message to HLR C 226. Once again, it will be 
appreciated that the DPC of the message 234 originally sent by the GMSC 
212 was the network address of the vHLR 214. That is, the GMSC 212 has 
knowledge of a message sent to the vHLR 214, but no knowledge of a 
particular message destined for HLR C 226. Implementation of such an SS7 
message routing scheme would therefore present a large problem for SS7 
network operators that have purchased and deployed a large number of 
network elements that operate in compliance with industry standard SS7 
communication protocols and network management procedures. 

Therefore, what is needed is a novel system and method of redirecting 
signaling messages among multiple HLR, EIR, AuC and other similar 
signaling database type nodes, where message routing occurs in such a way 
as to preserve compliance with existing industry standard network 
management signaling protocols. 

Disclosure of the Invention 
According to one aspect, the present invention includes a flexible 
routing node. The flexible routing node includes a communication module 
capable of transmitting and receiving data packets over a network. A range- 
based database contains range-based rule records indexed by blocks of 
identification numbers. An exceptions-based database contains exception- 
based rule records indexed by a single identification number. A database 
subsystem controller accesses at least one of the databases to extract routing 



information for the data packet. Because the flexible routing node includes 
both range- and exception based databases, flexibility in allocating mobile 
identification numbers among HLRs is increased. 

Accordingly, it is an object of the present invention to provide a flexible 
routing node capable of performing both range- and exception-based 
database lookups. 

It is another object of the present invention to provide a flexible routing 
node that complies with industry standard network management procedures. 

Some of the objects of the invention having been stated hereinabove, 
other objects will become evident as the description proceeds, when taken in 
connection with the accompanying drawings as best described hereinbelow. 

Brief Description of the Drawings 

Figure 1 is a network diagram illustrating a prior art GSM wireless 
telecommunication network architecture. 

Figure 2 is a network diagram illustrating a prior art GSM wireless 
telecommunication network implementation that includes a single HLR node. 

Figure 3 is a network diagram illustrating a prior art GSM wireless 
telecommunication network implementation that includes multiple HLR nodes. 

Figure 4 is a network diagram illustrating a prior art GSM wireless 
telecommunication network architecture. 

Figure 5 is a schematic diagram of a prior art signal transfer point 
switching node. 



x ' < -12- 

Figure 6 is a schematic network diagram illustrating a first routing 
database access scenario according to a preferred embodiment of a flexible 
routing node of the present invention. 

Figure 7 is a schematic network diagram illustrating a second routing 
5 database access scenario according to a preferred embodiment of a flexible 
routing node of the present invention. 

Figure 8 is a schematic network diagram illustrating an alternate 
network implementation of a flexible routing node of the present invention. 

Figure 9a is a table which illustrates a sample G-FLEX™ database 
10 structure used in a preferred embodiment of a flexible routing node of the 
present invention. 

Figure 9b is a table which illustrates a sample GTT database structure 
used in a preferred embodiment of a flexible routing node of the present 
invention. 

15 Figure 10a is a table which illustrates partial content of a signaling 

message received and processed by a flexible routing node of the present 
invention in a first example scenario. 

Figure 10b is a table which illustrates partial content of a signaling 
message received and processed by a flexible routing node of the present 
20 invention in a second example scenario. 

Figure 10c is a table which illustrates partial content of a signaling 
message received and processed by a flexible routing node of the present 
invention in a third example scenario. 

Figure 11 is a flow diagram illustrating the translation process 
25 implemented by a flexible routing node of the present invention. 



-13- 

Figure 12 is a network diagram illustrating the routing of short message 
service messages according to an embodiment of the present invention. 



Detailed Description of the Invention 
5 According to one embodiment, the present invention includes a flexible 

routing node for communicating with a GMSC and HLRs or SMSCs in a 
network. In a preferred embodiment, a flexible routing node employs an 
internal architecture similar to that of a high performance STP that is 
marketed by the assignee of the present application as the EAGLE® STP. A 

10 block diagram of an EAGLE® STP is shown in Figure 5. A detailed 
description of the EAGLE® STP may be found in the Eagle Feature Guide 
PN/91 10-1225-01, Rev. B, January 1998, published by Tekelec, the 
disclosure of which is hereby incorporated herein by reference. As described 
in this publication, an EAGLE® STP 250 includes the following subsystems: a 

15 Maintenance and Administration Subsystem (MAS) 252, a communication 
subsystem 254 and an application subsystem 256. The MAS 252 provides 
maintenance communications, initial program load, peripheral services, alarm 
processing and system disks. The communication subsystem 254 includes 
an Interprocessor Message Transport (IMT) bus that is the main 

20 communication bus among all subsystems in the EAGLE® STP 250. This 
high speed communications system functions as two 125 Mbps counter- 
rotating serial buses. 

The application subsystem 256 includes application cards that are 
capable of communicating with the other cards through the IMT buses. 

25 Numerous types of application cards can be incorporated into STP 250, 
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including: a Link Interface Module (LIM) 258 that provides SS7 links and X.25 
links, an Application Communication Module (ACM) 260 that provides a 
TCP/IP interface to an external monitoring device over Ethernet, and an 
Application Service Module (ASM) 262 that provides global title translation, 
gateway screening and other services. A Translation Service Module (TSM) 
264 may also be provided for local number portability. A detailed description 
of the EAGLE® STP is provided in the above cited Feature Guide and need 
not be described in detail herein. 

Figure 6 is a schematic diagram of a simplified GSM network 300 
including a flexible node 302 according to an embodiment of the present 
invention. In addition to the flexible routing node 302, GSM network 300 
generally includes; an SS7 signaling network 346, a Gateway Mobile 
Switching Center (GMSC) 348, an Internet Protocol (IP) network 350, a first 
Home Location Register (HLR) 352, a second HLR 354, and a third HLR 356. 

In the illustrated embodiment, flexible routing node 302 includes a high 
speed Interprocessor Message Transport (IMT) communications bus 304. 
Communicatively coupled to IMT bus 304 are a number of distributed 
processing modules or cards including: a pair of Maintenance and 
Administration Subsystem Processors (MASPs) 306, an SS7 enabled Link 
Interface Module (LIM) 308, an IP enabled Data Communication Module 
(DCM) 336, and a G-FLEX™ Database Module (GDM) 322. These modules 
are physically connected to the IMT bus 304 by bus interfaces 318, 324, and 
338, respectively. For simplicity of illustration, only a single LIM 308, GDM 
322, and DCM 336 are included in Figure 6. However, it should be 
appreciated that the distributed, multi-processor architecture of the node 302 



facilitates the deployment of multiple LIM, GDM, and DCM cards, all of which 
could be simultaneously connected to the IMT bus 304. 

MASP pair 306 implements the maintenance and administration 
subsystem functions described above. As the MASP pair 306 is not 
particularly relevant to a discussion of the flexible routing attributes of the 
present invention, the reader is referred to the above-mentioned Tekeiec 
EAGLE® publications for a more detailed description of these system 
components. 

Focusing now on LIM card functionality, in the illustrated embodiment 
LIM 308 is comprised of a number of sub-components including, but not 
limited to: an SS7 MTP level 1 and 2 layer process 310, an I/O buffer or 
queue 312, an SS7 MTP level 3 layer HMDC process 314, and an HMDT 
process 316. MTP level 1 and 2 layer process 310 provides the facilities 
necessary to send and receive digital data over a particular physical media / 
physical interface, as well as to provide error detection / correction and 
sequenced delivery of all SS7 message packets. I/O queue 312 provides for 
temporary buffering of incoming and outgoing signaling message packets. 
MTP level 3 HMDC process 314 performs a discrimination function, effectively 
determining whether an incoming SS7 message packet requires internal 
processing or is simply to be through switched, i.e., routed to another node. 
The HMDT process 316 handles the internal routing of SS7 message packets 
that require additional processing prior to final routing. 

In general, a GDM card provides the databases and database control 
processes necessary to perform the required network address translations to 
achieve the flexible routing functionality implemented by embodiments of the 
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present invention. The GDM 322 shown in Figure 6 is comprised, in part, of a 
Signaling Connection Control Part (SCCP) sub-module 326, which further 
includes a database subsystem controller known as a Signaling Connection 
Routing Controller (SCRC) process 328. The SCRC process 328 is 
5 responsible for number conditioning, the directing of incoming SS7 message 
packets to either a G-FLEX™ database process 330 or "a Global Title 
Translation (GTT) database process 332, and for modification of the message 
packets to include routing information returned by the G-FLEX™ or GTT 
database processes 330 and 332, respectively. SS7 message packets 

10 leaving SCRC process 328 are received and further processed by an HMRT 
process 334. The HMRT process 314 is responsible for the external routing 
of SS7 message packets that do not require additional processing by the 
flexible routing node 302. That is, the HMRT process 334 determines to 
which LIM or DCM card an SS7 message packet should be routed for 

15 subsequent outbound transmission. It will also be appreciated from Figure 6 
that GDM 322 is coupled to and serviced by an OAM subsystem 335 via an 
Ethernet connection 333. OAM subsystem 335 is responsible for 
administration and maintenance of the G-FLEX™ and GTT databases 330 
and 332, respectively. 

20 DCM 336, shown in Figure 6, includes an HMCG process 340 which is 

responsible for monitoring congestion on the associated DCM linksets, and 
internally communicating this link congestion information to peer processes on 
other modules via the IMT bus 304. Such link congestion information is used 
by the HMRT process 334 during outbound link selection operations. It 

25 should be appreciated that outgoing SS7 message packets routed through the 
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DCM 336 will be transmitted out of the flexible routing node 302 and into an 
Internet Protocol (IP) network 350. As the SS7 communication protocol and 
the IP communication protocol are not inherently compatible, all SS7 
message packets that are to be sent into the IP network 350 are first 
5 encapsulated within an IP routing envelope prior to transmission. This IP 
encapsulation is performed by an IP encapsulation process 342. The IP 
encapsulation process 342 is the IP protocol equivalent of the SS7 MTP level 
1-2 layer process 310 of the LIM module 308. Preferred packet formats for 
encapsulating various types of SS7 messages in IP packets is described in 

10 Internet Engineering Task Force (IETF) INTERNET DRAFT entitled Transport 
Adapter Layer Interface, May 28, 1999, the disclosure of which is incorporated 
herein by reference in its entirety. 

Once again, the description of LIM and DCM sub-components provided 
herein is limited to those sub-components that are relevant to the sample 

15 implementation scenarios illustrated in Figures 6 and 7. For a comprehensive 
discussion of additional LIM and DCM operations and functionality, the above- 
referenced Tekelec publications can be consulted. 

With particular regard to the scenario illustrated in Figure 6, the 
Gateway Mobile Switching Center 348 is communicatively coupled to the 

20 flexible routing node 302 via an SS7 communication link 320. More 
specifically, the GMSC node 348 is connected to LIM 308 via the SS7 
communication link 320. Connected to the external IP network 350 is the 
DCM module 336, via an IP communication link 344. Residing within and 
connected to the IP network 350 are the HLR nodes 352, 354, and 356. As 

25 such, an IP communication pathway exists between the DCM module 336 of 
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the flexible routing node 302 and each of the HLR nodes 352, 354, and 356. 
The IP communication pathway can be TCP/IP or UDP/IP. It should be 
appreciated that in an alternate embodiment of the flexible routing node 302 
according to an embodiment of the present invention, the communication 
5 protocol implemented between the GMSC 348 and the flexible routing node 
302 could be IP or another non-SS7 protocol, such as Asynchronous Transfer 
Mode (ATM) or Synchronous Optical Network (SONET). For instance, an IP 
communication link could just as effectively be used between the GMSC 348 
and the flexible routing node 302. In such a case, a suitably configured DCM 

10 module would be substituted for the LIM 308 shown in Figure 6. Likewise, the 
communication protocol implemented between the flexible routing node 302 
and the HLR nodes 352, 354, and 356 could be SS7, Interim Standard-41 (IS- 
41), GSM or another non-IP protocol. For example, an SS7 communication 
link could be employed between the flexible routing node 302 and the HLR 

15 nodes 352, 354, and 356. In such a case, multiple LIM modules would be 
substituted for the DCM 336 shown in Figure 6. 

As stated above, one problem associated with load sharing and 
number porting among multiple HLR nodes is that conventional MSCs and 
GMSCs are only capable of block-based addressing. Similarly, a problem 

20 faced by many mobile operators is that SMSC addresses must be given to 
subscribers or programmed into subscriber handsets. If multiple SMSCs are 
used, it can become very difficult to manage this subscriber to SMSC 
mapping. As such, it will be appreciated that one of the primary objectives of 
the flexible routing node according to an embodiment of the present invention 

25 is to provide a method by which a network operator can quickly and easily 
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direct signaling messages associated with a given calling or called party to a 
particular HLR or SMSC node. To facilitate such signaling message re- 
direction, the flexible routing node of the present invention employs a pair of 
complimenting routing databases which effectively map an IMSI or MSISDN 
5 number associated with a signaling message to the network address of the 
appropriate HLR or SMSC node. These databases, described above, are 
referred to as the G-FLEX™ database, and/or the GTT database. 

Figures 9a and 9b are database structure diagrams which are intended 
primarily to illustrate the key or indexing structures of the G-FLEX™ and GTT 

10 databases 330 and 332, respectively. It should be appreciated that the G- 
FLEX™ and GTT database record structures and pseudo data presented in 
Figures 9a and 9b, while supportive of the examples shown in Figures 6 and 
7, are merely illustrative of the basic information necessary to perform the 
required routing data lookups. In practice, the actual database record 

15 structures and overall database design may vary according to particular 
implementation requirements. 

The complimentary database access scheme employed by the flexible 
routing node of the present invention requires that the GTT database 332 
maintain a set of range or block-based routing rules while the G-FLEX™ 

20 database 330 contains exceptions to the block-based routing rules. Once 
again, this concept is generally illustrated in Figures 9a and 9b. By range or 
block-based routing rules, it is meant that a block or range of mobile 
identification numbers (IMSI, MSISDN, etc.) are associated with the network 
address of a particular HLR, EIR, AuC, Service Control Point (SCP), etc. 

25 Such a range-based routing rules database structure is similar to the routing 
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database structures commonly employed in conventional GMSC nodes, as 
described above. 

Referring to Figure 9b, the GTT or range-based database 332 includes 
key fields in the left hand column and data fields in the right hand column. 
The key fields represent ranges of mobile identification numbers associated 
with a particular node. For example, the first key field specifies a minimum 
mobile identification number of 9199670000 and a maximum mobile 
identification number of 9199679999. The data fields corresponding to this 
range include a Point Code (PC) of 3-0-2, a Subsystem Number (SSN) of 6, 
and a Routing Indicator (Rl) of RT-ON-SSN for the network element 
corresponding to the range in the key field. The data included in the data 
fields are merely illustrative of data fields that can be included in range-based 
or GTT database 332. Similar key fields and data fields are shown for other 
network elements. 

Referring to Figure 9a, the G-FLEX™ or exceptions-based database 
330 contains entries that are exceptions to the entries in the range-based 
database 332. In Figure 9a, the left-hand column includes key values for 
each entry, and the right hand column includes data fields for each entry. The 
first entry includes a key field value of 9193803833. The data fields 
corresponding to the first key field value include a point code (PC) of 3-0-3, a 
Subsystem Number (SSN) of 6, a Routing Indicator (Rl) of RT-ON-SSN, a 
Replace Called party Global Title digits (RCGT) value of NO, and an Entity 
Address 303211234, representing HLR C. These data fields are merely 
illustrative of the data fields that can be included in the exception-based or G- 
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FLEX™ database 330. The remaining entries in the database 330 contain 
similar data for other network elements. 

The dual database architecture employed in the flexible routing node of 
the present invention provides a number of subtle benefits to the network 
5 operator. For example, the complimenting nature of the two databases 
optimally minimizes routing database memory resource requirements. 
Furthermore, the task of maintaining and administering the flexible routing 
node is greatly simplified, in that only exceptions to the conventional block- 
based routing rules must be explicitly entered in the G-FLEX™ database. If 

10 such were not the case and, for example, a particular network operator had 
data associated with 500,000 mobile subscribers stored in a one or more 
HLRs, the network operator would be required to create and store at least one 
unique routing record for each of the 500,000 subscribers. The exceptions- 
based structure of the flexible routing node database system simply requires, 

15 in such a case, that the operator create and store individual routing records in 
the G-FLEX™ database only for those IMSI or MSISDN numbers that do not 
adhere to the range or block-based rules that have been specified in the GTT 
database. For example, if a number is ported from one HLR to another HLR, 
the MSISDN number may be an exception to the block based rules in the 

20 second HLR. In the special case where all of the operator's IMSI or MSISDN 
numbers adhere to the block-based rules specified in the GTT database, the 
G-FLEX™ database would be empty. At the other extreme, where all of the 
operator's IMSI or MSISDN numbers do not adhere to the general block- 
based rules specified in the GTT database, the G-FLEX™ database would 
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contain at least one entry for each of the operator's assigned mobile 
identification numbers. 

The flexible routing node according to the present invention facilitates 
load sharing among HLRs. For example, if a service provider originally has 
5 two HLRs in service and subsequently purchases a third HLR, the G-FLEX™ 
database allows numbers allocated to the original HLRs to be re-allocated to 
the new HLR. 

With regard to G-FLEX™ and GTT translation services, the parameters 
used either directly or indirectly to determine the type of translation service 

10 (e.g., G-FLEX™ service or GTT service) required by an incoming signaling 
message are included in Figures 10a - 10c. The left-hand column in each of 
Figures 10a-10c represents the parameters used to determine the type of 
translation service required. In the illustrated figures, these parameters 
generally include a Routing Indicator (Rl), Global Title indicator (GTI) 

15 parameter, a Translation Type (TT) parameter, a Numbering Plan (NP) 
parameter, and a Nature of Address Indicator (NAI) parameter. These 
parameters, their meanings within the context of an SS7 communication 
network, and their range of values are well known to those skilled in the art 
and consequently will not be discussed in detail. It should suffice to say that 

20 the preferred embodiment of the flexible routing node of the present invention 
relies on some or all of these parameters to determine the required translation 
service. 

The center column in each of Figures 10a-10c represents original 
values, i.e., before translation, for the parameters illustrated in each left hand 
25 column. The right-hand column in each of Figures 10a-10c illustrates the 
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values for each of the parameters in the left-hand column after translation. 
More specifically, the right-hand column in Figure 10a represents parameter 
values after a G-FLEX™ translation, which will be described with regard to 
Figure 6. The right-hand column of Figure 10b represents parameter values 
5 after a default global title translation, which will be described in detail with 
regard to Figure 7. Finally, the right hand column of Figure 10c represents 
parameter values after an intermediate global title translation, which will be 
described in detail with regard to Figure 8. 

Once the general type of translation service requirement has been 

10 made (i.e., G-FLEX™ translation or GTT translation), the specific type of 
translation service is next determined. With particular regard to G-FLEX™ 
translation services, the types of services available could include GSM 
services, such as HLR, SMSC, EIR, AuC, etc. Determination of the specific 
G-FLEX™ translation service is made through examination of a Subsystem 

15 Number (SSN) parameter that is contained in the Called Party Address 
(CdPA) field of the signaling message. Once again, the SSN parameter is 
well known to those skilled in the art and consequently will not be discussed in 
detail herein. It should suffice to say that the flexible routing node of the 
present invention is configured to recognize certain SSN values as indicating 

20 the need for a particular type of G-FLEX™ translation service. 

From an operational standpoint, signaling messages requiring routing 
database processing are first serviced by the exception-based G-FLEX™ 
database. That is, a lookup is performed in the G-FLEX™ database based on 
either the IMSI or MSISDN number associated with the incoming signaling 

25 message packet. In the event that an IMSI or MSISDN match is located in the 
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G-FLEX™ database, the appropriate routing data is returned by the G- 
FLEX™ database and the signaling message packet is modified accordingly 
before further routing. No secondary search of the block-based GTT 
database is required in such a case. However, in the event that no IMSI or 
MSISDN match is located in the G-FLEX™ database, a secondary search is 
performed in the range-based GTT database. 

G-FLEX™ Translation 
Figures 6 and 7 generally illustrate the two routing database access 
scenarios briefly described above. More particularly, Figure 6 diagrams the 
case where the initial G-FLEX™ database lookup finds an IMSI or MSISDN 
match and hence no secondary GTT database search is required. To 
illustrate this case, the path of a typical HLR-bound SS7 signaling message is 
traced from the GMSC 348, through the flexible routing node 302 and 
ultimately to the destination HLR C 356, with the path being indicated by a 
dashed line in Figure 6. For the purposes of illustration, each of these 
network nodes has been assigned an SS7 network address or point code 
(PC). In both Figures 6 and 7, GMSC node 348 is identified by the PC 1-0-0, 
flexible routing node 302 is identified by PC 2-0-0, while the three HLR nodes 
352, 354, and 356 are identified by the PCs 3-0-1, 3-0-2, and 3-0-3, 
respectively. 

Beginning at the GMSC node 348, a signaling message is formulated 
and transmitted to the flexible routing node 302 via the SS7 communication 
link 320. The relevant data content of this originating signaling message is 
shown in Figure 10a. As such, it will be appreciated from the table presented 
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in Figure 10a that the OPC of the original message is equal to 1-0-0, the PC 
of GMSC node 348. The DPC of the message is 2-0-0, the PC of the flexible 
routing node 302. The signaling message is received within the flexible 
routing node 302 by LIM 308. SS7 MTP Level 1 and 2 processing is 
5 performed on the incoming signaling message packet by the MTP Level 1 and 
2 process 310. With MTP Level 1 and 2 processing complete, the signaling 
message packet is temporarily buffered in the I/O queue 312 before being 
passed up the stack to the MTP Level 3 HMDC process 314. The HMDC 
process 314 examines the signaling message packet and determines whether 

10 the packet requires further processing at the flexible routing node 302. In the 
example shown in Figure 6, it is assumed that the HMDC process 314 
determines that further processing of the signaling message packet is 
required, and the packet is subsequently passed to the HMDT process 316. 
The HMDT process 316 examines the packet and determines, based on the 

15 type of further processing that is required, which distributed processing 
module connected to the IMT bus 304 should next receive the packet. In this 
case, the HMDT process 316 determines that the signaling message should 
be forwarded to GDM module 322 for G-FLEX™ translation service. The 
signaling message packet is then placed on the high speed IMT bus 304 and 

20 sent to GDM 322. A detailed flow chart of GDM/SCCP related processing 
steps is presented in Figure 11, and may be used in conjunction with the 
schematic diagram shown in Figure 6 to better understand the G-FLEX™ and 
GTT database lookup methodology. Furthermore, Figure 10a provides a 
summary of the contents of the signaling message packet before and after G- 

25 FLEX™ translation. 
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Referring to Figure 11, in step ST1, the signaling message arrives at 
the GDM card 322 and SCCP process 326 receives the packet. Within SCCP 
process 326, the message packet is passed to the SCRC controller process 
328. In steps ST2 and ST3, respectively, the SCRC process 328 decodes 
5 and examines packet content information contained within the signaling 
message header in order to establish which type of translation service is 
required. More particularly, the Rl, GTI, TT, NP, and NAI parameters 
contained within the signaling message packet are analyzed to determine 
whether a G-FLEX™ or a GTT translation service is required. As indicated in 

10 steps ST4 and ST5, if it is determined that GTT translation service is required, 
the message is passed directly to the GTT database process 332. However, 
in the scenario presented in Figure 6, an Rl value of "RT-ON-GT", a GTI value 
of 4, a Translation Type (TT) value of 0, a "national" NAI value, and an 
"E.164" NP value, are collectively interpreted as indicating the need for a G- 

15 FLEX™ translation. The signaling message content is then further analyzed 
to determine the specific type of G-FLEX™ translation service required, as 
indicated by step ST6. More particularly, the CdPA SSN parameter is 
examined, and the value of 6 is interpreted as indicating the need for a G- 
FLEX™ HLR type translation. In this particular example, if the entity type of 

20 the destination node is determined to be anything other than HLR or SMSC 
(i.e., SSN not equal to 6 or 8), the packet is passed to the GTT database 
process 332 as shown in steps ST7 and ST5, respectively. In step ST8, the 
mobile identification number (MIN) encoded within the packet is subsequently 
examined and conditioned, as necessary. The MIN is typically stored within 

25 the CdPA field in a structure commonly referred to as the Global Title Digits 
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(GTD) sub-field. In some cases, it may be necessary to retrieve the MIN from 
the TCAP/MAP information in the message. In this example, the MIN or GTD 
has a value of 9193803833, as shown in Figure 10a, and it is further assumed 
that no conditioning of this number is required. 

However, with regard to the above-mentioned number conditioning, 
such processing may be necessary to insure that the IMSI or MSISDN is 
compatible with the format of the key field data stored in the G-FLEX™ and 
GTT databases 330 and 332, respectively. Number conditioning operations 
might include the pre-pending extra digits to a mobile identification number 
contained within a signaling message packet so as to force the number to 
conform to an international format. Conversion of a mobile identification 
number from one numbering standard to another may also be performed. For 
instance, the mobile identification number associated with an incoming 
signaling message packet may be converted from a first industry standard 
format known as E.214 to a second industry standard format known as E.212 
prior to database lookup operations. Once again, it should be appreciated 
that such mobile identification number conditioning services are necessary 
only in the case that the format of the incoming message mobile identification 
number is not consistent with the corresponding key field data format in the G- 
FLEX ™ and GTT databases. 

In step ST9, the G-FLEX™ database 330 is searched using the 
appropriate mobile identification number (IMSI or MSISDN) as at least a 
portion of the search key. If a match is not found in the G-FLEX™ database 
330, the packet is passed to the GTT database 332 for processing, as shown 
in steps ST10 and ST11, respectively. However, in the example presented in 
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Figure 6, a match is found in the G-FLEX™ database 330, as indicated by the 
fact that there is an entry in the G-FLEX™ database 330 (Figure 9a) 
corresponding to the message's CdPA SSN value of 9193803833. The 
routing data returned by the G-FLEX™ database process 330, a point code 
value of 3-0-3 and a subsystem number of 6, is subsequently encoded within 
the signaling message packet, as indicated by step ST12. It will be 
appreciated that the routing information, PC:3-0-3 SSN:6, returned by the G- 
FLEX™ database effectively constitutes the network address of HLR C 356. 
It should also be appreciated that the Routing Indicator (Rl) field of the 
translated signaling message has been modified from the original "Route-On- 
GT" value to a new value of "Route-On-SSN", indicating that no further routing 
address translations are required to identify the network address of the 
destination HLR node. Once again, the Routing Indicator parameter is well 
known to those skilled in the art of SS7 telecommunications, and 
consequently a detailed discussion of this parameter and its routing 
functionality is not presented herein. It will be appreciated, however, that this 
parameter is used to generally indicate whether a signaling message packet 
requires SCCP type processing. It should also be noted in Figure 9a that two 
of the stored data fields are not used in this case. An Entity Address field is 
used to store an alias, typically an MSISDN or IMSI formatted number, that is 
representative of a particular HLR or SMSC node. A Replace Called party 
Global Title digits (RCGT) field contains a flag that indicates whether the 
value in the CdPA:GTD field of the signaling message should be changed to 
reflect the Entity Address of the destination HLR node. In this case it will be 
appreciated that the RCGT flag is set to a value of "NO", indicating that the 
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CdPA:GTD field of the signaling message need not be changed to reflect the 
Entity Address of HLR C. Such is typically the case, when the point code and 
subsystem information corresponding to the network address of a target HLR 
node is already known by the flexible routing node. If, however, the flexible 
routing node has not been provisioned with at least the point code 
corresponding to the destination HLR node, then an Entity Address 
substitution is employed to facilitate subsequent routing address translations 
by an external routing node. An example of such a scenario is provided 
below. 

Returning now to Figure 6, it will be appreciated that following the 
successful G-FLEX™ database lookup as described in detail above, the 
modified signaling message packet is next passed to the HMRT process 334. 
Once again, the HMRT process 334 determines to which LIM or DCM card 
the packet should be routed for subsequent transmission to the message's 
destination node. In this case, the HMRT process 334 determines that the 
link connecting the flexible routing node 302 and the modified message's 
destination node is located on DCM 336. Consequently, the modified 
signaling message packet is internally routed across the IMT bus 304 to DCM 
336, where it is received by the HMCG process 340. HMCG process 340 
passes the modified message packet into the I/O queue 341, while 
acknowledging this outbound packet's contribution to link congestion. 
Eventually, the modified message packet is passed from the I/O queue 341 
and on to IP process 342, where the SS7 packet is encapsulated within an IP 
routing envelope. The IP encapsulated SS7 packet is then transmitted into 
the associated IP network 350 via the IP signaling link 344. In this example, 
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the IP encapsulated SS7 packet is addressed and consequently routed 
through the IP network 350 to the final destination, HLR C 356. The OPC of 
the packet is changed to the OPC of flexible routing node 302. 

Default GTT Translation 
Turning now to Figure 7, the example message flow scenario 
presented in this diagram illustrates the case where an initial G-FLEX™ 
database lookup fails to find an IMSI or MSISDN match and hence a 
secondary or default GTT database search is required. The path of a typical 
HLR-bound SS7 signaling message is traced from the GMSC 348, through 
the flexible routing node 302 and ultimately to the destination HLR B 354. 
Once again, the signaling message pathway is indicated by a dashed line. 
Beginning at the GMSC node 348, a signaling message is formulated and 
transmitted to the flexible routing node 302 via the SS7 communication link 
320. The relevant data content of this originating signaling message is shown 
in Figure 10b. As such, it will be appreciated from the table presented in 
Figure 10b that the OPC of the original message is equal to 1-0-0, the PC of 
GMSC node 348. The DPC of the message is 2-0-0, the PC of the flexible 
routing node 302. 

As processing of the incoming signaling message packet on the LIM 
308 in this scenario is identical to that described for the scenario illustrated in 
Figure 6 and described above, a detailed discussion of LIM processing will not 
be repeated. Instead, it will be appreciated that the incoming signaling 
message is received within the flexible routing node 302 by LIM 308 and that 
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the message packet is subsequently examined and routed via IMT bus 304 to 
GDM card 322 for further processing. 

The detailed flow chart of GDM/SCCP related processing steps 
presented in Figure 11 can be used in conjunction with the schematic diagram 
shown in Figure 7 to better understand the G-FLEX™ and GTT database 
lookup methodology. Furthermore, Figure 10b provides a summary of the 
contents of the signaling message packet before and after G-FLEX™ 
translation. Referring to Figure 1 1, in step ST1, the signaling message arrives 
at the GDM card 322 and SCCP process 326 receives the packet. Within 
SCCP process 326, the message packet is passed to the SCRC controller 
process 328. In steps ST2 and ST3, respectively, the SCRC process 328 
decodes and examines packet content information contained within the 
signaling message header in order to establish which type of translation 
service is required. More particularly, the Rl, GTI, TT, NP, and NAI 
parameters contained within the signaling message packet are analyzed to 
determine whether a G-FLEX™ or a GTT translation service is required. 
Once again, as in the preceding example, a Rl value of "RT-ON-GT", a GTI 
value of 4, a TT value of 0, a "national" NAI value, and an "E.164" NP value, 
are collectively interpreted as indicating the need for a G-FLEX™ translation. 
The signaling message content is then further analyzed to determine the 
specific type of G-FLEX™ translation service required, as indicated by step 
ST6. More particularly, the CdPA SSN parameter is examined, and the value 
of 6 is interpreted as indicating the need for a G-FLEX™ HLR type translation. 
In step ST8, the mobile identification number (MIN) encoded within the packet 
is subsequently examined and conditioned, as necessary. In this example, 



-32- 

the MIN or GTD has a value of 7707883438, as shown in Figure 10b, and it is 
further assumed that no conditioning of this number is required. 

In step ST9, the G-FLEX™ database 330 is searched using the 
appropriate mobile identification number (IMSI or MSISDN) as at least a 
portion of the search key. In this case, a match is not found in the G-FLEX™ 
database 330 and the packet is passed to the GTT database 332 for further 
processing, as shown in step ST10. It will be appreciated that this GTT 
default processing is indicated by the fact that there is not an entry in the G- 
FLEX™ database 330 (Figure 9a) corresponding to the message's CdPA 
SSN value of 7707883438. Consequently, in step ST10, the GTT database 
332 is searched using the mobile identification number, 7707883438, as at 
least a portion of the search key. As indicated in Figure 9b, a MIN range is 
defined in the GTT database 332 which bounds the searched MIN, 
7707883438. The routing data returned by the GTT database process 332, a 
point code value of 3-0-2 and a subsystem number of 6, is subsequently 
encoded within the signaling message packet, as indicated by step ST12. It 
will be appreciated that the routing information, PC:3-0-2 SSN:6, returned by 
the GTT database 332 effectively constitutes the network address of HLR B 
354. It should also be appreciated that the Routing Indicator (Rl) field of the 
translated signaling message has been modified from the original "Route-On- 
GT" value to a new value of "Route-On-SSN". 

Returning now to Figure 7, it will be appreciated that following the 
unsuccessful G-FLEX™ and successful GTT database lookup sequence as 
described in detail above, the modified signaling message packet is next 
passed to the HMRT process 334. Once again, the HMRT process 334 
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determines to which LIM or DCM card the packet should be routed for 
subsequent transmission to the message's destination node. In this case, the 
HMRT process 334 determines that the link connecting the flexible routing 
node 302 and the modified message's destination node is located on DCM 
336. Consequently, the modified signaling message packet is internally 
routed across the IMT bus 304 to DCM 336, where it is received by the 
HMCG process 340. HMCG process 340 passes the modified message 
packet into the I/O queue 341, while acknowledging this outbound packet's 
contribution to link congestion. Eventually, the modified message packet is 
passed from the I/O queue 341 and on to IP process 342, where the SS7 
packet is encapsulated within an IP routing envelope. The destination IP 
address in the routing envelop can be determined by database lookup in the 
DCM for the IP address corresponding to point code 3-0-2. The IP 
encapsulated SS7 packet is then transmitted into the associated IP network 
350 via the IP signaling link 344. In this example, the IP encapsulated SS7 
packet is addressed and consequently routed through the IP network 350 to 
the final destination, HLR B 354. 

As stated above, the IP network 350 illustrated in Figure 7 may be 
replaced by an SS7 network without departing from the scope of the 
invention. In such a scenario, the DCM 336 can be replaced by a second LIM 
for routing outgoing SS7 messages over an SS7 network. In a method for 
routing a signaling message according to such an embodiment, the steps for 
routing the signaling message are the same as those described above prior to 
distribution of the message to the DCM 336, as described above. However, 
when the DCM 336 is replaced by a LIM, rather than encapsulating the 
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signaling message in an IP packet, the signaling message is simply routed to 
HLR B 354 according to the destination point code of the message. The 
outgoing signaling message has an OPC equal to the point code of flexible 
routing node 302 and a DPC equal to the point code of HLR B 354. Because 
the OPC of the signaling message is changed to the point code of flexible 
routing node 302, rather than that of the GMSC 348, compliance with SS7 
network reliability procedures is maintained. 

Intermediate Translation 

Another example, presented in Figure 8, is intended to illustrate an 
alternate network implementation in which it is possible for a flexible routing 
node of the present invention to provide an intermediate routing translation. 
In this implementation, signaling network 400 includes a flexible routing node 
402, which is substantially identical in form and function to the flexible routing 
node 302 described above and generally illustrated in Figures 6 and 7. 
Flexible routing node 402 is coupled to GMSC 348 and the three HLR nodes 
352, 354, and 356 via at least one intermediate STP 404. The communication 
link 406 between flexible routing node 402 and STP 404 is an SS7 link, 
although other communication protocols, such as IP, could also be employed. 

In this scenario, the path of a typical HLR-bound SS7 signaling 
message is traced from the GMSC 348, through the flexible routing node 402 
and ultimately to the destination node, HLR A 352. Once again, the signaling 
message pathway is indicated by a dashed line. The relevant data content of 
this signaling message as it is first received and then translated by the flexible 
routing node 402 is shown in Figure 10c. Beginning at the GMSC node 348, 
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a signaling message with a CdPA:GTD value of 2125662322 is formulated 
and transmitted to the intermediate STP 404. STP 404 receives and routes 
the signaling message on to the flexible routing node 402 via communication 
link 406. Although not shown in Figure 10c, it will be appreciated that the 
OPC of the original message is equal to 1-0-0, the PC of GMSC node 348, 
while the DPC of the original message is 4-0-0, the PC of the STP 404. In the 
process of routing the message packet, STP 404 modifies the OPC to 4-0-0 
and the DPC to 2-0-0. The message is then transmitted by STP 404 to the 
flexible routing node 402, which is assigned the point code 2-0-0. Once the 
signaling message is received by the flexible routing node 402, processing of 
the message is essentially the same as that described above for the previous 
examples. 

The only significant difference in this case is that the routing data 
returned by the G-FLEX™ database lookup is not the point code and SSN of 
the target HLR A node 352, but is instead the Entity Address associated with 
HLR A 352 and the point code of STP 404. More particularly, a Replace 
Called party Global Title digits (RCGT) value of "YES" is returned by the G- 
FLEX™ database as indicated in Figure 9a, along with an HLR A Entity 
Address value of 1013211234. Consequently, the original value of the 
CdPA:GTD field of the signaling message, 2125662322, is replaced by the 
HLR A Entity Address value of 101321 1234. 

A second key distinction from the previous example scenarios is that 
the CdPA routing indicator of the translated message is set to "RT-ON-GT" 
instead of "RT-ON-SSN", thereby indicating that a least one more routing 
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address translation will be required to determine the actual network address 
of the destination HLR node. 

Those skilled in the art of SS7 routing systems will appreciate that such 
a translation is very similar in form and function to an intermediate global title 
translation. As such, it is implied that the G-FLEX™ and GTT databases 
contained within flexible routing node 402 do not have the information 
necessary to identify the actual network address of the target destination 
node. However, the G-FLEX™ database is populated with information 
relating to the next network routing node that might have the actual network 
address of the target destination node. As indicated in Figures 8, 9a and 10c, 
the result of the G-FLEX™ database lookup indicates that the signaling 
message packet should be next routed to STP 404 at PC: 4-0-0. 
Furthermore, the routing indicator of the translated message is set to a value 
of "RT-ON-GT", indicating that a final routing translation is still required before 
the message packet can reach it's target destination. In this example, it is 
assumed that STP 404 is configured to perform a successful final GTT on the 
message packet using the Entity Address of HLR A that has been stored in 
the CdPA:GTD field of the signaling message. Following this final GTT 
translation at STP 404, the DPC of the message packet is changed to 3-0-1:6, 
and the message is subsequently transmitted to the network element 
corresponding to this PC and SSN, namely HLR A 352. The OPC of the 
message is changed to 4-0-0, that is, the OPC of the STP 404. 

As alluded to previously, one significant distinction that the flexible 
routing node of the present invention has over prior art solutions involves the 
manner in which the OPC field of the SS7 MTP routing label is altered during 
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the G-FLEX™ or GTT translation process. More particularly, as part of the G- 
FLEX™ and GTT processing, the OPC of the translated signaling message is 
modified to reflect the point code of the flexible routing node. This distinction 
is significant in that it enables industry standard SS7 level 3 and above 
network management protocols to operate in compliance with accepted SS7 
telecommunications standards as defined by ANSI, ITU, Telcordia, and 
others. 

SMS Message Routing 

As stated above, one problem in conventional mobile communications 
networks is assigning existing mobile subscribers to new SMSCs as new 
SMSCs are added to a network. This problem stems from the fact that the 
entity address for the SMSC is either hard coded or programmed into the 
subscribers' handsets. If new SMSCs are added, the subscribers' handsets 
must either be reprogrammed or an alternate SS7 message routing scheme 
must be implemented. The flexible routing node according to an embodiment 
of the present invention includes functionality for routing messages to a 
specific SMSC in a network that includes multiple SMSCs without requiring 
the reprogramming of mobile handsets. 

Figure 12 is a network diagram illustrating a network that includes 
multiple SMSCs. Referring to Figure 12, network 500 includes flexible routing 
node 402, MSC 502, IWMSC 504, SMSC A 506 and SMSC B 508. Flexible 
routing node 402 includes exceptions and range-based databases as 
illustrated in Figures 9a and 9b, respectively. However, unlike the examples 
described above which relate primarily to routing messages to HLRs, an 
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example will now be described in which flexible routing node 402 routes 
messages to SMSCs 506 and 508. 

When a user desires to send a short message to another user, mobile 
handset 128 sends the data and the mobile identification number of the 
intended recipient to MSC 502. MSC 502 receives the data from the handset 
and sends a short message service message to flexible routing node 402. 
The short message service message includes a mobile application part (MAP) 
portion including the mobile identification number of originating handset 128. 
The short message service message may also include the entity address of 
the SMSC that was originally programmed into handset 128. However, rather 
than using this entity address, which is stored in the SCCP portion of the 
message, flexible routing node 402 uses the MIN in the MAP portion of the 
message to decide whether to route the message to SMSC A 506 or SMSC B 
508. 

When flexible routing node 402 receives the short message service 
message from MSC 502, the message is identified as an SCCP message that 
requires G-FLEX processing in the manner described above, i.e., based on 
the service selector, translation type, numbering plan, and nature of address 
indicator parameters in the message. In addition to these parameters, the 
subsystem number parameter is examined to determine the entity type of the 
node to which the message should be routed. This SSN-to-entity type 
mapping may be performed by SCRC process 328 using an entity type table 
provisioned on GDM 322 illustrated in Figure 7. An example of such an entity 
type table is as follows: 
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Subsystem Number 


Entity Type 


6 


HLR 


8 


SMSC 



Table 1 : SSN to Entity Type Mapping 



Referring to Figure 9a, once the message is identified as having an 
entity type of SMSC, a lookup is performed in exceptions-based database 330 
5 using the MiN from the MAP portion of the message. In Figure 9a, if the MIN 
in the MAP portion of the message is 4143286672, the destination entity 
address for the message is 4146773497, which corresponds to SMSC B 508. 
Flexible routing node 402 inserts the entity address of SMSC B 508 in the 
called party address field of the message, inserts the point code 6-0-1 in the 

1 0 DPC field in the MTP part of the message, and routes the message to !WMSC 
504 illustrated in Figure 12. IWMSC 504 routes the message to SMSC B 508. 
SMSC B 508 receives the short message service message and sends a short 
message service message to the destination mobile handset. 

If the lookup in exceptions-based database 330 using the MIN from the 

15 MAP portion of the message fails. A lookup occurs in range-based database 
332 using the entity address in the called party address field of the SCCP 
portion of the message. In this case, the message would be routed to an 
SMSC based on the entity address for that SMSC in database 332. 

Thus, flexible routing node 402 illustrated in Figure 12 allows short 

20 message service messages to be routed to an SMSC in a network that 
includes multiple SMSCs. This routing can be performed without requiring the 
mobile handsets of a mobile telecommunications service provider to be 
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changed when a new SMSC is added to the network. Thus, the flexible 
routing node according to the present embodiment greatly reduces the burden 
on mobile telecommunications service providers when adding new SMSCs to 
a network. 

It will be understood that various details of the invention may be 
changed without departing from the scope of the invention. Furthermore, the 
foregoing description is for the purpose of illustration only, and not for the 
purpose of limitation-the invention being defined by the claims. 



